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(57) The invention is directed to a method for a soft- 
ware provider to enable a software-acquiring entity to 
arrive from an existent first signed piece of code at a 
second signed piece of code. Both pieces of code were 
generated at the software provider by use of a first soft- 
ware archive generator under use of generation instruc- 
tions. The software provider provides to the software- 
acquiring entity a difference code that comprises the 
steps necessary to arrive from the first signed piece of 
code at the second signed piece of code. The difference 
code is combinable at the software-acquiring entity with 
the first signed piece of code by a second software ar- 
chive generator to generate the second signed piece of 
code. The second software archive generator is therefor 
to be fed with those generation instructions that were 
used by the first software archive generator for the gen- 
eration of both pieces of code. 
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Description 

[0001] The invention relates to a method for a soft- 
ware provider of enabling a software-acquiring entity to 
arrive from an existent first signed piece of code at a 5 
second signed piece of code. The invention also relates 
to a method for a software-acquiring entity of arriving 
from an existent first signed piece of code at a second 
signed piece of code. 

10 

TECHNICAL FIELD AND BACKGROUND OF THE 
INVENTION 

[0002] Today's typical Java applications tend to be 
very large, consisting of even thousands of classes. 15 
Moreover, as the prevalent webbrowsers executing 
Java code require different Java packaging and signing 
formats, code is usually distributed twice, thereby fur- 
ther increasing the application's size. This increased 
complexity leads to ever more programming errors to 20 
become evident only when the programs are already 
rolled out to the customers. This necessitates bug fixes 
to be sent to the customers. As the Java programs are 
shipped in cryptographically signed containers, so far, 
the complete Java containers, possibly containing thou- 25 
sands of classes, need to be re-distributed, even when 
only one single class file therein has been changed. 

OBJECT AND ADVANTAGES OF THE INVENTION 

30 

[0003] It is an object of the invention according to the 
independent claims to provide a method which reduces 
the amount of data to be transmitted while facilitating a 
change in functionality and retaining the security prop- 
erties of signed code such as Java code containers. 35 
[0004] Thus, the primary problem solved here is the 
reduction of the amount of data to be shipped to cus- 
tomers when modifying a first piece of code to arrive at 
a second piece of code, e.g. for correcting errors in 
code, or upgrading code to new feature sets. 40 
[0005] The invention is hence directed to a method for 
a software provider to enable a software-acquiring entity 
to arrive from an existent first signed piece of code at a 
second signed piece of code. Both pieces of code were 
generated at the software provider by use of a first soft- 45 
ware archive generator under use of generation instruc- 
tions. The software provider provides to the software- 
acquiring entity a difference code that comprises the 
steps necessary to arrive from the first signed piece of 
code at the second signed piece of code. The difference 50 
code is combinable at the software-acquiring entity with 
the first signed piece of code by a second software ar- 
chive generator to generate the second signed piece of 
code. The second software archive generator is therefor 
fed with those generation instructions that were used by 55 
the first software archive generator for the generation of 
both pieces of code. 

[0006] The first software component-merging unit 



makes use of the generation instructions for generating 
the first signed piece of code. Since at the user those 
generation instructions are used to generate the second 
signed piece of code, it is of advantage if the generation 
instructions are provided to the software-acquiring entity 
by the software provider, preferably together with the 
second software archive generator. Thereby a better 
guaranty exists that the user is in possession of a set of 
tools that permit the correct generation of the second 
signed piece of code. 

[0007] The system at the software provider side may 
further comprise a signature unit which has access to a 
private key. The pieces of code are signed using that 
private key. The public/private key system is a very 
widespread and well-known system for encryption 
which hence is easy to implement and use. 
[0008] It is of advantage if the difference code is cre- 
ated, preferably by the first software archive generator, 
while the first software archive generator generates the 
second signed piece of code. Since the difference code 
refelcets the steps of how to arrive at the second piece 
of code, the information to be put into the difference file 
is automatically created and available during the gener- 
ation process. 

[0009] For the software-acquiring entity the method of 
arriving from an existent first signed piece of code at a 
second signed piece of code whereby both pieces of 
code have been generated at the software provider by 
use of the first software archive generator under use of 
generation instructions comprise the steps of 

sending a code amendment request to the software 
provider for the delivery of a difference code which 
comprises the steps necessary to arrive from the 
first signed piece of code at the second signed piece 
of code, 

receiving the difference code and combining it with 
the first signed piece of code by use of a second 
software archive generator thereby generating the 
second signed piece of code. The second software 
archive generator is fed with those generation in- 
structions that were used by the first software ar- 
chive generator for the generation of both pieces of 
code. The user has the advantage of only using a 
small difference code instead of the whole new sec- 
ond signed piece of code. Downloading the differ- 
ence code via a network may take significantly less- 
er time. For the software provider this holds also 
true. Also the costs for providing the difference file 
will be lower than the cost of a full version of the 
second signed piece of code 

[0010] The proposed method can be realized and 
marketed in form of a computer program product com- 
prising program code for performing the proposed meth- 
od. This computer program product can be stored on a 
computer-readable medium. 
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SUMMARY OF THE INVENTION 

[0011] To understand the invention, first, the existing 
situation is described in more detail. It is assumed that 
an entity, such as a natural or a legal person, who has 
acquired a specific piece of code, the person in the fol- 
lowing also referred to as user, wants to replace this 
code by a different piece of piece of code, bothe codes 
also referred to as software, preferably an updated ver- 
sion of the previously acquired piece of software. In the 
following it is, for the sake of giving a concrete example, 
assumed that the user wants to have an update for his 
already acquired software. Typically, the user requests 
the update at the origin of the already acquired piece of 
software. The originator of the software then may send 
an updated full version of the software to the user, or a 
software which when being executed in the presence of 
the not-yet updated software alters the existing software 
to then be the updated software. In case of signed soft- 
ware, i.e. where the integrity and originality of the soft- 
ware can be verified using a private/public key encryp- 
tion scheme, such an update hitherto required the orig- 
inator of the software to send a complete version of the 
update, since assembling of the previously acquired 
software together with the update in practically all cases 
would lead to a different signature which would be rec- 
ognized by a verifier tool as non-original. It is however 
in the interest of the user to use the signature of a signed 
software to be able to distinguish the original, i.e. un- 
touched by unauthorized hands, software from software 
that has been modified by some unauthorized entity. 
The user wants this benefit of the signature to persist 
also when an update is made. The user is also referred 
to as client and the software provider is also referred to 
as server. This, because a typical realization could be 
that the software provider does not act in person but has 
the providing function automized in a computer system, 
such as a server which automatically performs the nec- 
essary steps for providing the user who runs aclient sys- 
tem, with the desired update code. On the user side the 
update request plus the eventual performing of the up- 
date can be automized in a computerized system, called 
the client. 

[0012] A solution is proposed which uses crypto- 
graphically protected difference files permitting the re- 
creation of cryptographic signatures for the code to be 
updated. The approach presented for the re-creation of 
the client-side software's signatures has the advantage 
that it does not require the use of any new cryptographic 
functionality on the client side, but restricts this to the 
server-side, and the third-party execution environ- 
ments, e.g., the webbrowsers. Software built on this 
general strategy has the advantage that it does not fall 
under any export restrictions, since it does not use cryp- 
tographic methods. Moreover, it is obviously more se- 
cure, as the signature key, i.e. the private key of the soft- 
ware provider, is not required on the client side to re- 
create the signatures. 



[0013] The invention uses a novel approach to se- 
curely update signed applications already installed and 
deployed in the field over an inherently insecure medi- 
um, such as the Internet. It covers various techniques 

5 to make the above goal achievable in a very efficient 
manner. In essence, the concept could also be de- 
scribed to use online versioning check, combined with 
open security protocols, and differentiating techniques 
applied to signed document formats such as JAR or 

10 CAB. 

DESCRIPTION OF THE DRAWINGS 

[0014] Examples of the invention are depicted in the 
15 drawings and described in detail below by way of exam- 
ple. It is shown in 

fig. 1 : a schematic overview over the involved steps and 
units in an exchange of code between a user and a soft- 
ware provider. 

20 [001 5] All the figures are for sake of clarity not shown 
in real dimensions, nor are the relations between the di- 
mensions shown in a realistic scale. 

DETAILED DESCRIPTION OF THE INVENTION 

25 

[0016] In the following, the various exemplary embod- 
iments of the invention are described. 

1st embodiment 

30 

[0017] In figure 1, a storage unit 1 is depicted which 
contains a database containing several signed pieces 
of code 11, 12, 13. These signed pieces of code 11, 12, 
1 3 have been generated by a first software archive gen- 
35 erator 2, also denoted with AG. The first software ar- 
chive generator 2 comprises a first software component- 
merging unit 21 which makes use of generation instruc- 
tions 8. 

[0018] It further comprises a signature unit 22 which 
40 has access to a private key 1 4. In the depicted example, 
four software components 9, denoted with A, B, C, D, 
are fed to the first software archive generator 2 which 
according to the generation instructions 8 and version 
instructions 26 assembles these software components 
45 g to an assembly, also referred to as an archive or a 
container. 

[0019] For each piece of code 11,12, 13 these version 
instructions 26 contain the code-specific information of 
what is to be included in that particular piece of code 1 1 , 

50 12, 13, how and where it is to be included. Hence here 
for the first signed piece of code 11 , it contains rules RV1 
which tell that the three components A, B, C are to be 
put in, in exactly that order. For the second signed piece 
of code 12, it contains rules RV2 which tell that the two 

55 components A, C are to be put in, in exactly that order. 
For the third signed piece of code 13, it contains rules 
RV3 which tell that the three components A, D, C are to 
be put in, in exactly that order. The generation instruc- 
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tions 8 are of a more general kind, giving instructions 
that are relevant for the generation of any signed piece 
of code 11, 12, 1 3. This assembly is then signed by the 
signature unit 2, using the private key 14. The genera- 
tion leads to three different versions here: A first version 
V1.0, a second version V2.0 and a third version V3.0. 
The first version V1 .0 has a signature Sig 1 1 and with it 
builds a first signed piece of code 11. The second ver- 
sion V2.0 has a signature Sig 12 and with it builds a 
second signed piece of code 1 2. The third version V3.0 
has a signature Sig 13 and with it builds a third signed 
piece of code 1 3. In this concrete example, the first ver- 
sion V1 .0 consists of the three software components A, 
B, C plus the signature Sig 1 1 , the second version V2.0 
consists only of the two software components A, C plus 
the signature Sig 12, and the third version V3.0 consists 
of the three software components A, D, C plus the sig- 
nature Sig 13. 

[0020] As described above, these three pieces of 
code 11, 12, 13 are stored in the storage unit 1. The 
storage unit 1 is connected to a difference code gener- 
ator 1 0 which delivers its output to an output unit 3 which 
is combined with an input unit 24. So far the infrastruc- 
ture on the side of a software provider 25 has been de- 
scribed. 

[0021] On the side of a software-acquiring entity 20, 
also called user 20, a second software archive genera- 
tor 7 is present which contains a software component 
separator 23 and a second software component-merg- 
ing unit 27 which is operable under use of the generation 
instructions 8 which are identical to those on the soft- 
ware provider side. The user 20 has the first signed 
piece of code 11 and desires to amend it to the second 
signed piece of code 1 2. Therefore the user 20 sends a 
code amendment request 16 which is accompanied by 
an identifier that gives the information which update is 
desired, to the software provider 25 via an input/output 
unit 6 to the input unit 24. The identifier here tells that 
the user 20 needs an update from the version V1.0 to 
the version V2.0 of the software SW1 . The identifier can 
be a version number describing the current feature set 
and may be any character string, or numerical value. 
[0022] The code amendment request 16 is received 
in the input unit 24 of the software provider 25 and in 
suit thereof the difference code generator 1 0 compares 
the two versions V1 .0 and V2.0 and generates a corre- 
sponding difference code DV(SW1 ) which here is a first 
difference code 4, i.e. DV12(SW1). The content of this 
code are the instructions for amending the first version 
V1 .0 into the second version V2.0 and tell that the soft- 
ware component B is to be removed and the signature 
Sig 11 is to be removed and replaced by the signature 
Sig 12. The difference code generator is hence a tool 
for extracting the differences in contents and the signa- 
tures of two signed container files tools, namely the first 
signed piece of code 11 and the scond signed piece of 
code 12. The exact order of all entries contained in an 
updated and signed container are recorded. 



[0023] The first difference code 4 contains hence all 
steps necessary to arrive, starting from the first piece of 
code 11, at the second piece of code 12. These steps 
are given with a precision that is necessary for the soft- 

5 ware archive generator 7 on the user side to generate 
the second signed piece of code 1 2 in a way that in the 
end, the signature Sig 12 which belongs to the second 
piece of code 12 is the correct signature for the then 
updated piece of code on the user side. One could say 

10 that the difference file 4 reflects the version instructions 
26 for the user 20, such that at the user 20 only the gen- 
eration instructions 8 are needed. 
[0024] The verification of the signature Sig 1 1 , Sig 1 2, 
Sig 1 3 of a specific piece of code issues a specific result 

15 that depends on the internal structure of the code, since 
typically a hashing technique is used for signing. For a 
signature Sig 1 1 , Sig 1 2, Sig 1 3 to be correctly identified 
and verified for a certain piece of code, hence the inter- 
nal structure of that piece of code must be identical to 

20 the internal structure of the piece of code that was 
signed, because the private/public key cryptosystem 
ensures that with a extraordinarily high probability the 
results for two different pieces of code are different. This 
applies to any of the typically used encryption schemes 

25 which base on an inherent asymmetry in that the time 
used for generating an encrypted file is much shorter, 
typically several orders of magnitude, than the time that 
would be needed for arriving from the encrypted file at 
the unencrypted file. The latter time in practical cases 

30 exceeds human lifetime which is hence defined as se- 
cure in terms of encryption. 

[0025] It has hence to be ensured that the process on 
the user side for amending the first piece of software 1 1 
into the second piece of software 12 is done in a way 

35 that guarantees that the resulting second signed piece 
of code 12 has the exact internal structure as had the 
original second signed piece of code 12 as it was gen- 
erated and signed on the software provider side. The 
first difference code 4 together with the generation in- 

40 structions 8 and the component-merging unit 21 form a 
toolbox that guarantees that the generation process on 
the user side matches the generation process on the 
software provider side. This matching ensures that the 
internal structure of the second signed piece of code 1 2 

45 when it is generated on the user side is identical to the 
internal structure of the second signed piece of code 1 2 
as it is stored on the software provider side. 
[0026] Once the first difference code 4 has been re- 
ceived at the input/output unit 6, it is forwarded to the 

50 second software archive generator 7. There, the first 
piece of code 1 1 is first separated into its software com- 
ponents 9 which are then merged by the component- 
merging unit 21 according to the generation instructions 
8 and the instructions contained in the first difference 

55 code 4. The result is the second signed piece of code 
12 with its signature Sig 12. 

[0027] The subsequent verification with the crypto- 
graphical verification unit under the use of the public key 
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1 5 hence must result in a positive verification result 1 9. 
[0028] With this method, only the difference code 4 
had to be transmitted and not the whole second piece 
of code 12. In case of large pieces of code, the differ- 
ence in size between the second piece of code 12 and 
the difference code 4 can be very big and of enormous 
impact, thinking of transfer costs for electronic transmis- 
sion for example. The transmission of small pieces of 
code via an electronic network like the Internet takes 
less time and is cheaper and less prone to interruptions 
and data losses compared to the transmission of pieces 
of code with big size. The transmission does not need 
to be done via an electronic network but can be made 
in any human or machine-readable form and via any 
suitable medium, such as in printed form, printers and 
scanners, mails-systems or hand-carried or via optical 
networks, or as magnetically stored data. The difference 
code 4 is also referred to as update or difference file. 
[0029] The second software archive generator 7 is 
able to process the update 4, i.e., merging the new up- 
date 4 into the existing first signed piece of code 11 al- 
ready installed at the user 20. The advantage lies in the 
fact that the update 4 contains the exact order of con- 
tents that is adhered to by the client-side second soft- 
ware archive generator 7 for re-creating the exact same 
code container structure as present on the server-side 
when signing the software 1 1 being updated. This allows 
the client-side to correctly re-create the updated soft- 
ware 12 intact as far as the signature and the contents 
are concerned. 

2nd embodiment 

[0030] Extending the above described example, it is 
assumed that the user 20 wants to arrive from the first 
signed piece of code 1 1 at the third signed piece of code 
1 3. For this update, in principle two steps are necessary, 
namely a first update using the first difference code 4 
for arriving from the first signed piece of code 11 at the 
second signed piece of code 12 and a second update 
using the second difference code 5 to arrive from the 
second signed piece of code 1 2 at the third signed piece 
of code 13. There exist several possibilities therefor: 

a) The difference code is determined for exactly the 
transition from the first signed piece of code 11 to 
the third signed piece of code 13. The difference 
code generator 10 can do this by comparing those 
two signed pieces of code 11, 13. 

b) The user 20 receives the two difference codes 4, 
5 and one update is performed after the other in the 
second software archive generator 7. This is how- 
ever considered as not very elegant and puts the 
burden to the user 20 who has to cope with two up- 
dates which is more clumsy and probably also slow- 
er. Actions in the first update that have become re- 
dundant because the later update cancels them, 



waste time and bandwidth if the difference codes 4, 
5 have been transmitted via a network. This situa- 
tion exacerbates with rising number of intermediate 
updates necessary to perform the overall upgrade. 

5 

c) The two difference codes 4, 5 are combined to 
the overall difference code which then is transmitted 
to the user 20. 

w [0031] The difference codes 4, 5 need not be deter- 
mined upon request of the user 20 but can also be pre- 
determined at any point in time before and can be stored 
e.g. also in the database. The response to the code 
amendment request can of course be faster when the 
15 difference code 4, 5 was pre-generated and stored be- 
fore. In the case of a huge number n of different versions 
Vx.x this method will however lead to a huge number of 
update difference codes 4, 5, namely theoretically n*(n- 
1 )/2 different difference codes 4, 5 if every possible up- 
20 date combination is pre-generated and stored. A simpli- 
fied scheme would be to only pregenerate the difference 
codes 4 from a subset of the possible combinations. In 
the case of a series of subsequent updates, this set 
could contain a difference code 4, 5 from each version 
25 Vx.O to its subsequent version V(x+1).0. Thereby a 
chain of difference codes 4, 5 is pre-generated which 
comprises only n-1 different difference codes 4, 5. If a 
request for an update arrives that covers several steps 
of updates, i.e. difference codes 4, 5, the corresponding 
30 difference codes 4, 5 can be combined as suggested 
under c) above. In realistic cases, the probability of such 
update requests is typically much smaller than the prob- 
ability of update requests from one version to its subse- 
quent version. 

35 [0032] The communication betwen the user 20 and 
the software provider 25 can be made using an authen- 
tication scheme. The two involved parties, i.e. the user 
20 and the software provider 25, thereby can determine 
whether the other party is trustable and is not another 
40 party pretending to be the true other party. This authen- 
tication process facilitates communication and avoids 
situations in which after the update the verification re- 
sults the recognition of a fraudulous update attempt. 
[0033] The authentication scheme could be integrat- 
es ed as follows: 

The server 25 on the software provider side is run- 
ning an authentication protocol like the SSL proto- 
col requiring client-authentication. 

50 

The server 25 maintains a repository of the signed 
pieces of code 11, 12, 13, also referred to as soft- 
ware files, indexed by version numbers describing 
all possible versions previously handed out to the 
55 user 20, i.e. customer. The server 25 may also have 
stored the signed difference files 4 contain ing all da- 
ta and all signature-related information necessary 
to transform a given software file into another soft- 
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ware file, preferably the most current software ver- 
sion. 

On the client side runs a client code, such as a SSL 
client code, that may be used to establish a secure 5 
connection to the above server 25. 

The client side authentication software further con- 
tains a cryptographic certificate and a key that was 
contained in the original software distribution, e.g., 10 
on a personalized disk coming with a product CD 
carrying the original software file code, that can be 
used to perform a client-authentication protocol with 
the software-distributing server 25. This way, the cli- 
ent 20 can make sure that the server 25 it talks to 15 
is an authentic server 25, and the server 25 knows 
that the client 20 it talks to is eligible for the software 
update 4. 

The software update 4 is transmitted over this se- 20 
cure connection to the client 20. 

The client 20 checks the update's contents: In par- 
ticular, the version information contained in the soft- 
ware update 4, 5 is checked if it is appropriate, pos- 25 
sibly identical, to the current version present on the 
client 20. 

The client side software then extracts all data nec- 
essary and joins it into the existing software 11 al- 30 
ready present at the client 20. In particular, the order 
of contents in all signed code containers is appro- 
priately restored such that the signatures attain their 
functionality and correctness originally created on 
the server-side. 35 

In the final step, all signatures Sig 11, Sig 12, Sig 
13 contained in the update file 4, 5 received from 
the server 25 are applied to the appropriate files, i. 
e., the signed code containers, e.g. the Netscape 40 
JAR or Microsoft CAB files. 

[0034] The approach outlined above may be applied 
to any form of data requiring continued updates, while 
being signed with one of the file formats discussed 45 
above, e.g. Microsoft CAB or Netscape JAR. 
[0035] The scenario described above can be aug- 
mented or replaced by a non-connection-oriented sce- 
nario, in which the difference file itself is cryptographi- 
cally protected. This makes sense, if no online connec- 50 
tion to the software distribution server 25 can be estab- 
lished, or is not desirable. In that case, the server-side 
software distribution facility applies a cryptographic sig- 
nature Sig 11, Sig 12, Sig 13 to the difference file 4, 5 
that is checked by the client-side update software in a 55 
manner equivalent to the secure-session establishment 
in the online SSL connection establishment outlined 
above. The file formats suitable for this approach are 



the same formats that may be handled internally, i.e., e. 
g., Netscape/Sun JAR or Microsoft CAB. 
[0036] Even without authentication the signature Sig 
11 , Sig 12, Sig 13 provides a degree of security which 
is not corrupted by the update process. The verification 
namely issues a negative result if, for whatever reason, 
the signature Sig 11, Sig 12, Sig 13 that is part of the 
updated second piece of code 1 2 is not correct, i.e. does 
not match the expected signature Sig 11, Sig 1 2, Sig 1 3 
that is calculated by using the public key 15. In such a 
case the non-matching signature Sig 1 1 , Sig 1 2, Sig 1 3 
signals that something went wrong and that the update 
is not to be trusted. The user 20 may hence decide not 
to use the updated second piece of code 1 2, since some 
unauthorized modification may have introduced a secu- 
rity problem which might harm the user 20. If the user 
20 has kept a backup copy of the first signed piece of 
code 11, he can delete the updated version 12 and he 
still has the original first signed piece of code 1 1 to use. 
[0037] The described embodiments are combinable 
in part as well as in whole. For the sake of understanding 
it is to be noted that when an update is referred to, the 
invention is not rerstricted to software updates, but can 
be applied to perform a step from a first signed piece of 
code 11 to a second, third, etc. piece of code 12, 13, ... 
while maintaining the advantage and correctness of the 
signature that has been created for the first signed piece 
of code 11. As a software archive generator 2, 7 any 
piece of code respectively its hardware version is meant 
that performs the function of putting together software 
components in order to unify them as a single software 
product or computer program, particularly in order to de- 
liver it to a customer or other entity. 
[0038] It is obvious for the person skilled in the art that 
the present invention can be realized in hardware, soft- 
ware, or a combination of these. Also, it can be imple- 
mented in a centralized fashion on one single computer 
system, or in a distributed fashion where different ele- 
ments are spread across several interconnected com- 
puters or computer systems, whereby any kind of a com- 
puter system - or other apparatus adapted for carrying 
out the methods described herein - is suited. A typical 
combination of hardware and software could be a gen- 
eral purpose computer system with a computer program 
that, when being loaded and executed, controls the 
computer system such that it carries out the methods 
described herein. The present invention can also be em- 
bedded in a computer program product, which compris- 
es all the features enabling the implementation of the 
methods described herein, and which-when loaded in a 
computer system - is able to carry out these methods. 
[0039] Computer program means or computer pro- 
gram in the present context mean any expression, in any 
language, code or notation, of a set of instructions in- 
tended to cause a system having an information 
processing capability to perform a particular function ei- 
ther directly or after either or both of the following a) con- 
version to another language, code or notation; b) repro- 
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duction in a different material form. 
[0040] Any disclosed embodiment may be combined 
with one or several of the other embodiments shown 
and/or described. This is also possible for one or more 
features of the embodiments. 

[0041 ] It is obvious that a person skilled in the art can 
modify the shown arrangements in many ways without 
departing from the gist of the invention which is encom- 
passed by the subsequent claims. 



Claims 

1. Method for a software provider (25) of enabling a 
software-acquiring entity (20) to arrive from an ex- 
istent first signed piece of code (11) at a second 
signed piece of code (12, 13), both pieces of code 
(11, 12, 13) having been generated by use of a first 
software archive generator (2) under use of gener- 
ation instructions (8), comprising the step of provid- 
ing to said software-acquiring entity (20) a differ- 
ence code (4, 5) comprising the steps necessary to 
arrive from said first signed piece of code (11) at 
said second signed piece of code (12, 13), which 
difference code (4, 5) is usable at said software-ac- 
quiring entity (20) to be combined with said first 
signed piece of code (1 1 ) by a second software ar- 
chive generator (7) to generate said second signed 
piece of code (12, 13), whereby said second soft- 
ware archive generator (7) is to be fed with those 
generation instructions (8) that were used by said 
first software archive generator (2) for the genera- 
tion of both pieces of code (11, 12, 13). 

2. Method according to claim 1, wherein the genera- 
tion instructions (8) are provided to the software-ac- 
quiring entity (20) by the software provider (25), 
preferably together with the second software ar- 
chive generator (7). 

3. Method according to claim 1 or 2, wherein the piec- 
es of code (11, 12, 13) are signed using a private 
key (14). 

4. Method according to one of claims 1 to 3, wherein 
the signed pieces of code (1 1 , 1 2, 1 3) are stored in 
a storage unit (1) at the software provider (25). 

5. Method according to one of claims 1 to 4, wherein 
the difference code (4, 5) is created, preferably by 
the first software archive generator (2), while said 
first software archive generator (2) generates the 
second signed piece of code (12, 13). 

6. Method according to one of claims 1 to 5, wherein 
for more than two pieces of code (11, 12, 13) being 
stored, the difference code (4, 5) is generated only 
between a subset of said pieces of code (11,12,13). 



7. Method according to claim 6, wherein for arriving 
from the first piece of code (1 1 ) to the second piece 
of code (13) several difference codes (4, 5) are re- 
quired, these difference codes (4, 5) are merged to 

5 a single difference code to be provided to the soft- 

ware-acquiring entity (20). 

8. Method according to one of claims 1 to 7, wherein 
the first and second piece of code (11, 12, 13) are 

10 identified at the software provider (25) by deriving 
a corresponding identifier from a request (16) re- 
ceived from the software-acquiring entity (20). 

9. Method for a software-acquiring entity (20) of arriv- 
es ing from an existent first signed piece of code (11) 

at a second signed piece of code (12,1 3), both piec- 
es of code (11, 12, 13) having been generated at a 
software provider (25) by use of a first software ar- 
chive generator (2) under use of generation instruc- 
20 tions (8), comprising the steps of 

sending a code amendment request (16) to 
said software provider (25) for the delivery of a 
difference code (4, 5) which comprises the 
25 steps necessary to arrive from said first signed 

piece of code (1 1 ) at said second signed piece 
of code (12, 13), 

receiving said difference code (4, 5), 

30 

combining said difference code (4, 5) with said 
first signed piece of code (1 1 ) by use of a sec- 
ond software archive generator (7), thereby 
generating said second signed piece of code 
35 (1 2, 1 3), whereby said second software archive 

generator (7) is fed with those generation in- 
structions (8) that were used by said first soft- 
ware archive generator (2) for the generation 
of both pieces of code (11, 12, 13). 

40 

10. Method according to claim 9, wherein the genera- 
tion instructions (8) are received from the software 
provider (25), preferably together with the second 
software archive generator (7). 

45 

1 1 . Method according to claim 9 or 1 0, wherein the piec- 
es of code (11, 12, 13) are signed by use of a private 
key (1 4) and the signature (Sig 1 1 , Sig 1 2, Sig 1 3) 
is verifiable by use of a corresponding public key 

50 (15). 

1 2. Method according to one of claims 9 to 1 1 , wherein 
the first and second piece of code (11, 12, 13) are 
identified by the software-acquiring entity (20) by 

55 giving a corresponding identifier in the code amend- 
ment request (1 6). 

13. Computer program product comprising program 
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code means for performing a method according to 
one of the preceding claims. 

14. Computer program product according to claim 12, 
comprising the program code means stored on a 5 
computer-readable medium. 

15. Code amendment enabler enabling a software-ac- 
quiring entity (20) to arrive from an existent first 
signed piece of code (1 1 ) at a second signed piece 10 
of code (12, 13), both pieces of code (11, 12, 13) 
having been generated by use of a first software ar- 
chive generator (2) under use of generation instruc- 
tions (8), comprising 

15 

a difference code generator (1 0) for generating 
a difference code (4, 5) that comprises the 
steps necessary to arrive from said first signed 
piece of code (1 1 ) at said second signed piece 
of code (1 2, 1 3), which difference code (4, 5) is 20 
usable at said software-acquiring entity (20) to 
be combined with said first signed piece of code 
(1 1 ) by a second software archive generator (7) 
to generate said second signed piece of code 
(12,1 3), whereby said second software archive 25 
generator (7) is fed with the generation instruc- 
tions (8), 



of both pieces of code (11, 12, 13). 

19. Code amendment device according to claim 18, fur- 
ther comprising an input/output unit (6) for sending 
a code amendment request (16) to said software 
provider (25) and for receiving said difference code 
(4, 5). 



an output unit (3) for providing to said software- 
acquiring entity (20) said difference code (4, 5). 30 



16. Code amendment enabler according to claim 15, 
further comprising an input unit (24) for receiving 
from said software-acquiring entity (20) a code 
amendment request (1 6) for the delivery of said dif- 35 
ference code (4, 5). 

17. Code amendment enabler according to claim 1 5 or 
1 6, further comprising a first software archive gen- 
erator (2) for generating said pieces of code (11,12, 40 
13) under use of generation instructions (8). 



18. Code amendment device for arriving from an exist- 
ent first signed piece of code (11) at a second 
signed piece of code (12, 13), both pieces of code 45 
(11, 12, 13) having been generated at a software 
provider (25) by use of a first software archive gen- 
erator (2) under use of generation instructions (8), 
comprising 

50 

a second software archive generator (7) for 
combining a received difference code (4, 5) 
with said first signed piece of code (11), thereby 
generating said second signed piece of code 
(12,1 3), whereby said second software archive 55 
generator (7) is to be fed with those generation 
instructions (8) that were used by said first soft- 
ware archive generator (2) for the generation 
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